NotifySession only pulls address as needed directly from the DBus
object. To simplify access for the Bless object, and not force all other
backends to function asynchronously, we implement this small capture of
the address at start

For harmonized request objects to use in read and write callbacks

Three levels of callback points are defined
backend-interface:      __on_<verb>
backend-server:         _on_<verb>
user-defined:           on_<verb>

The backend interface is where the backend such as CoreBluetooth, WinRT,
or BlueZ have their respective objects and are consumed and packaged
into Bless specific objects and passed to the backend-server

At the backend-server, the server then is responsible for routing the
callback either to the specific characteristic or to the general
user-defined callback

The user-defined callback is then able to process the same bless objects
and responses as needed.

The characteristics have properties for tracking subscribed central
devices. Previously, we were manaully tracking these. Keep it simple and
consistent by using the properties already available.

With characteristics managing subscriptions, the base sever can now
compupte whether the server has subscriptions using the generic
characteristics

These changes allow for defining a GATT tree of services and
characteristics as a single dictionary hierarchy that can be set in one
swoop. Callbacks for inidividual characteristics may be defined on this
dictionary tree.

May remove this if this should be a user-desired feature rather than
forcing it